-
Notifications
You must be signed in to change notification settings - Fork 61
Conversation
b8c28ac
to
fecbab4
Compare
Oh it actually looks like valgrind doesn't have any problem on CI... I have something on my debian testing, might come back on ptest, as it usually does. |
fecbab4
to
bca0838
Compare
Codecov Report
@@ Coverage Diff @@
## master #1195 +/- ##
==========================================
+ Coverage 77.36% 77.53% +0.17%
==========================================
Files 168 168
Lines 9861 9870 +9
==========================================
+ Hits 7629 7653 +24
+ Misses 2232 2217 -15
Continue to review full report at Codecov.
|
bca0838
to
ef03877
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks cool! I think I even understand most of what is going on.
TemporaryDirectory treehub_dir; | ||
boost::process::child ostree_server_process("tests/sota_tools/treehub_server.py", std::string("-p"), treehub_port, | ||
std::string("-d"), treehub_dir.PathString(), std::string("-s0.5"), | ||
std::string("--create")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you still need the treehub_server
if you are using the fake_test_server
? I'd hoped when I wrote that for it to be able to handle all server tasks in one script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't tried, to be honest. This test is mostly a mix-and-match of other tests that we have.
However:
- treehub_server also generates a repository at startup which the test uses
- there is the cgi / multipart business that I don't quite understand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem. It'd be nice to clean up our various test servers, but it doesn't need to be done now. We can come to back to that later if you'd like.
Actually, do you think we could convince OSTree to incorporate the ability to fake a deployment somehow? It seems like something not completely unreasonable, although if it is much more complicated than what you've already done, it may or may not be worth it. |
Signed-off-by: Laurent Bonnans <[email protected]>
Also, rename addImage to addBinaryImage Signed-off-by: Laurent Bonnans <[email protected]>
Signed-off-by: Laurent Bonnans <[email protected]>
Signed-off-by: Laurent Bonnans <[email protected]>
I was using it for a unit test but decided it wasn't actually useful for that, but it still may be useful for other purposes. Signed-off-by: Patrick Vacek <[email protected]>
To be added to LD_PRELOAD for advanced mocking Signed-off-by: Laurent Bonnans <[email protected]>
8af7118
to
b24bc4b
Compare
With some parts mocked (emulate booted deployments) Signed-off-by: Laurent Bonnans <[email protected]>
Signed-off-by: Laurent Bonnans <[email protected]>
b24bc4b
to
cb99aa6
Compare
Hm, I don't really see ourselves convincing them to do that work for us, as I don't know if others have similar needs and that's the kind of work that could make the code base more complex without added functionality. But could be possible if we have a somehow lightweight concrete plan (maybe make some hardcoded paths configurable?) and present a PR in an almost working state. Would require some more investigation on our side, though. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But could be possible if we have a somehow lightweight concrete plan (maybe make some hardcoded paths configurable?) and present a PR in an almost working state. Would require some more investigation on our side, though.
I agree wholeheartedly with your statements. The biggest part seems to be configuring hardcoded paths as you mention. Would you mind making a ticket and sharing it (or tagging me) to describe the work of that investigation? We don't need to worry about it now, but it be might worth looking into at a later time and/or if someone gets bored.
And by the way, thanks for merging the two fake servers! And for figuring all of this out in general! Seems quite cool and should enable a lot more extensive tests, too.
One thing I forgot: marking the test as done in actions.md and linking it with a comment. I'm not going to hold this up just for that, though.
Signed-off-by: Laurent Bonnans <[email protected]>
Added updates to actions.md. |
Nice work, I think, it's quite useful to fake the ostree work. |
Finally :).
Well, almost:
fake_http_server.py
andfake_test_server.py
, they share most of their code and both have similar non-descriptive names